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Abstract 

Automated  composition  of  Web  Services  can  be  achieved  by  using  AI  planning  techniques. 
Hierarchical  Task  Network  (HTN)  planning  is  especially  well-suited  for  this  task.  In  this 
paper,  we  describe  how  HTN  planning  system  SHOP2  can  be  used  with  OWL-S  Web  Ser¬ 
vice  descriptions.  We  provide  a  sound  and  complete  algorithm  to  translate  OWL-S  service 
descriptions  to  a  SHOP2  domain.  We  prove  the  correctness  of  the  algorithm  by  showing  the 
correspondence  to  the  situation  calculus  semantics  of  OWL-S.  We  implemented  a  system 
that  plans  over  sets  of  OWL-S  descriptions  using  SHOP2  and  then  executes  the  resulting 
plans  over  the  Web.  The  system  is  also  capable  of  executing  information-providing  Web 
Services  during  the  planning  process.  We  discuss  the  challenges  and  difficulties  of  using 
planning  in  the  information-rich  and  human-oriented  context  of  Web  Services. 


1  Introduction 


As  Web  Services  -  that  is,  programs  and  devices  accessible  via  standard  Web  pro¬ 
tocols  -  proliferate,  it  becomes  more  difficult  to  find  the  specific  service  that  can 
perform  the  task  at  hand.  It  becomes  even  more  difficult  when  there  is  no  single 
service  capable  of  performing  that  task,  but  there  are  combinations  of  existing  ser¬ 
vices  that  could.  Sufficiently  rich,  machine-readable  descriptions  of  Web  Services 
would  allow  the  creation  of  novel,  compound  Web  Services  with  little  or  no  direct 
human  intervention.  Semantic  Web  languages,  such  as  the  Web  Ontology  Language 
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(OWL)  [1]  or  its  predecessor  DAML+OIL[2],  provide  the  foundations  for  such  suf¬ 
ficiently  rich  descriptions. 

The  OWL-services  language  [3]  (OWL-S) 1 ,  is  a  set  of  ontologies  for  describing 
the  properties  and  capabilities  of  Web  services.  The  OWL-S  is  designed  to  support 
effective  automation  of  various  Web  Services  related  activities  including  service 
discovery,  composition,  execution,  and  monitoring. 

For  our  work,  we  are  motivated  by  issues  related  to  automated  Web  Service  compo¬ 
sition.  The  OWL-S  process  ontology  provides  a  vocabulary  for  describing  the  com¬ 
position  of  Web  Services.  This  ontology  uses  an  “action”  or  “process”  metaphor  for 
describing  Web  Service  behavior  -  that  is,  primitive  and  complex  actions  with  pre¬ 
conditions  and  effects. 

Given  a  representation  of  services  as  actions,  we  can  exploit  AI  planning  techniques 
for  automatic  service  composition  by  treating  service  composition  as  a  planning 
problem.  Ideally,  given  a  user’s  objective  and  a  set  of  Web  Services,  a  planner 
would  find  a  collection  of  Web  Services  requests  that  achieves  the  objective.  We 
believe  that  HTN  planning  is  especially  promising  for  this  purpose,  because  the 
concept  of  task  decomposition  in  HTN  planning  is  very  similar  to  the  concept  of 
composite  process  decomposition  in  OWL-S  process  ontology.  In  this  paper,  we 
explore  how  to  use  the  SHOP2  HTN  planning  system[4,5]  to  do  automatic  compo¬ 
sition  of  OWL-S  Web  Services. 

In  Section  2,  we  describe  a  sample  scenario  for  our  research.  In  Section  3,  we  give 
the  background  knowledge  about  OWL-S  process  ontology  and  SHOP2.  In  Section 
5,  we  present  our  approach  for  automatic  Web  services  composition.  In  Section  4, 
we  describe  why  we  think  HTN  planning  is  suitable  for  Web  Service  composition. 
In  Section  6,  we  describe  the  implementation.  In  Section  7  we  discuss  the  chal¬ 
lenges  and  difficulties  of  using  planning  for  composing  Web  Services  on  Semantic 
Web.  In  Section  8,  we  summarize  some  related  work.  And  finally,  in  Section  9,  we 
conclude  our  work  and  present  some  future  research  directions.  Throughout  this 
paper,  we  use  the  example  we  described  in  Section  2  to  illustrate  our  approach. 
But  our  work  is  designed  to  be  domain-independent  and  is  not  restricted  to  this 
example. 


2  Motivating  Example 


The  example  we  describe  here  is  based  loosely  on  a  scenario  described  in  the  Scien¬ 
tific  American  article  about  the  Semantic  Web  [6].  Suppose  Bill  and  Joan’s  mother 
goes  to  her  physician  complaining  of  pain  and  tingling  in  her  legs  and  the  physician 


1  The  previous  version  of  OWL-S  was  called  DAML-S  and  was  based  on  DAML+OIL 
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proposes  the  following  sequence  of  activities: 


•  A  prescription  for  Relafen,  an  anti-inflammatory  drug; 

•  An  MRI  scan  and  an  electromyography,  both  of  these  are  diagnostic  tests  to  try 
to  determine  possible  causes  for  the  symptoms; 

•  A  follow-up  appointment  with  the  physician  to  discuss  the  results  of  the  diag¬ 
nostic  tests. 

Bill  and  Joan  need  to  do  the  following  things  for  their  mother: 

•  Fill  the  prescription  at  a  pharmacy; 

•  Make  appointments  to  take  their  mother  to  the  two  treatments; 

•  Make  an  appointment  for  the  doctor’s  follow-up  meeting. 

For  the  three  appointment  times,  there  are  the  following  preferences  and  constraints: 

•  For  the  two  treatments: 

•  Bill  and  Joan  would  prefer  two  appointment  times  that  are  close  together  sched¬ 
uled  at  one  or  two  nearby  places,  so  that  only  one  person  needs  to  drive,  and 
that  person  drives  only  once. 

■  Otherwise,  they  would  prefer  two  appointment  times  on  different  days,  so  that 
each  person  needs  to  drive  once. 

•  The  appointment  time  for  doctor’s  follow  up  check  must  be  later  that  the  ap¬ 
pointment  times  for  the  two  treatments. 

•  An  appointment  time  must  fit  the  schedule  of  the  person  that  will  drive  to  the 
appointment. 

Assume  that  there  are  the  requisite  Web  Services  for  finding  appointment  times  and 
making  appointments  at  the  relevant  clinics.  Bill  and  Joan  could  use  those  services 
to  schedule  their  mother’s  appointments.  It  would  be  difficult  for  Bill  and  Joan  to 
finish  their  task  with  an  optimal  plan  by  consulting  the  Web  Services  manually, 
because: 

•  They  may  have  to  try  every  available  pair  of  close  appointment  times  at  any  two 
nearby  treatment  centers  in  order  to  find  one  that  fits  their  schedules. 

•  Furthermore,  if  they  first  choose  an  appointment  time  for  one  treatment  and  then 
find  they  have  to  use  this  same  time  for  the  other  treatment,  then  they  will  have 
to  reschedule  the  first  appointment. 

Instead,  suppose  we  use  the  OWL-S  process  ontology  to  encode  a  description  of 
how  to  use  Web  Services  to  accomplish  tasks  such  as  the  one  faced  by  Bill  and 
Joan.  If  we  have  an  automated  system  which  can  find  an  execution  path  based  on 
these  predefined  task  decompositions,  then  we  can  perform  Bill  and  Joan’s  Web 
Services  composition  task  automatically. 
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3  Background 


3.1  OWL-S 


In  the  OWL-S  process  ontology,  operations  are  modeled  as  processes.  There  are 
three  kinds  of  processes:  atomic  processes,  composite  processes  and  simple  pro¬ 
cesses.  In  OWL-S,  an  atomic  process  is  a  model  of  a  “single  step”  (from  the 
point  of  view  of  the  client)  Web  Service  that  is  directly  executed  to  accomplish 
some  task.  Executing  an  atomic  process  consists  of  calling  the  corresponding  Web- 
accessible  program  with  its  input  parameters  bound  to  particular  values.  A  com¬ 
posite  process  represents  a  compound  Web  Service,  i.e.,  it  can  be  decomposed 
into  other  atomic,  simple  or  composite  processes.  The  decomposition  of  a  com¬ 
posite  process  is  specified  through  its  control  constructs.  The  set  of  control  con¬ 
structs  includes:  Sequence,  Unordered,  Choice,  If-Then-Else,  Iterate,  Repeat- 
Until,  Repeat- While,  Split  and  Split+Join.  A  simple  process  is  an  abstraction  of 
an  atomic  or  composite  process  (or  of  a  possibly  empty  set  of  these).  It  is  not  con¬ 
sidered  to  be  directly  executable,  but  provides  an  abstract  view  of  an  action.  Like 
atomic  processes,  simple  processes  are,  themselves,  single-step,  but  unlike  atomic 
processes,  it’s  possible  to  peek  at  the  internal  structure  of  a  simple  process  (if  avail¬ 
able)  or  to  replace  the  simple  process  with  an  expansion  of  it. 

In  the  process  ontology,  each  process  has  several  properties,  including,  (optional) 
inputs,  preconditions,  (conditional)  outputs  and  (conditional)  effects.  Preconditions 
specify  things  that  must  be  true  of  the  world  in  order  for  an  agent  to  execute 
a  service.  Effects  characterize  the  physical  side-effects  that  execution  of  a  Web- 
service  has  on  the  world.  Inputs  and  Outputs  correspond  to  knowledge  precondi¬ 
tions  and  effects.  That  is,  necessary  states  of  our  knowledge  base  before  execution 
and  modifications  to  our  knowledge  base  as  a  result  of  the  execution.  Note  that 
not  all  services  have  significant  side-effects,  in  particular,  services  that  are  strictly 
information-providing  do  not.  Here  is  part  of  the  OWL-S  (version  0.9)  definition 
of  an  atomic  process  called  PharmacyLocator  used  in  our  treatment  scheduling  ex¬ 
ample: 

<owl : Class  rdf : ID=" PharmacyLocator" > 

<rdf s : subClassOf  rdf : resource^" ^process ; #AtomicProcess" / > 

</ owl : Class> 

<owl : Ob ject Property  rdf : ID="LocationPreference"> 

<rdf s : subPropertyOf  rdf : resource="&process ; # input " /> 

<rdf s : domain  rdf : resource^" #PharmacyLocator" / > 

<rdfs:range  rdf : resource=  "&concepts; #LocationPreference"/> 
</owl : Ob ject Property > 
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The  process  model  of  a  compound  Web  Service  includes  the  designation  of  the 
top-level  composite  process  corresponding  to  that  service  plus  a  decomposition  of 
that  composite  process  into  a  structured  collection  of  (perhaps  further  decomposed) 
subprocesses.  2  Web  Services  composition  is  sometimes  thought  of  as  the  process 
of  generating  a  (potentially)  complexly  structured  composite  process  description 
which  is  subsequently  executed.  On  this  model,  composite  processes  are  the  output 
of  composition.  In  this  paper,  we  take  composite  processes  as  input  to  a  planner,  that 
is,  as  descriptions  of  how  to  compose  a  sequence  of  single  step  actions.  Thus,  for 
us,  the  goal  of  automated  Web  services  composition  is  find  a  collection  of  atomic 
processes  instances  which  form  an  execution  path  for  some  top-level  composite 
process. 


3.2  SHOP2 


SHOP2  is  a  domain-independent  HTN  planning  system,  which  won  one  of  the  top 
four  awards  out  of  the  14  planners  that  competed  in  the  2002  International  Planning 
Competition.  HTN  planning  is  an  AI  planning  methodology  that  creates  plans  by 
task  decomposition.  HTN  planners  differ  from  classical  AI  planners  in  what  they 
plan  for,  and  how  they  plan  for  it.  The  objective  of  an  HTN  planner  is  to  produce 
a  sequence  of  actions  that  perform  some  activity  or  task.  The  description  of  a  plan¬ 
ning  domain  includes  a  set  of  operators  similar  to  those  of  classical  planning,  and 
also  a  set  of  methods,  each  of  which  is  a  prescription  for  how  to  decompose  a  task 
into  subtasks.  Planning  proceeds  by  using  methods  to  decompose  tasks  recursively 
into  smaller  and  smaller  subtasks,  until  the  planner  reaches  primitive  tasks  that  can 
be  performed  directly  using  the  planning  operators. 

One  difference  between  SHOP2  and  most  other  HTN  planning  systems  is  that 
SHOP2  plans  for  tasks  in  the  same  order  that  they  will  later  be  executed.  Planning 
for  tasks  in  the  order  that  those  task  will  be  performed  makes  it  possible  to  know 
the  current  state  of  the  world  at  each  step  in  the  planning  process,  which  makes 
it  possible  for  SHOP2’s  precondition-evaluation  mechanism  to  incorporate  signifi¬ 
cant  inferencing  and  reasoning  power  and  the  ability  to  call  external  programs.  This 
makes  SHOP2  ideal  as  a  basis  for  integrating  planning  with  external  information 
sources,  including  Web  based  ones. 

In  order  to  do  planning  in  a  given  planning  domain,  SHOP2  needs  to  be  given  the 
knowledge  about  that  domain.  A  SHOP2  knowledge  base  consists  of  operators  and 
methods  (plus,  various  non-action  related  facts  and  axioms).  Each  operator  is  a 
description  of  what  needs  to  be  done  to  accomplish  some  primitive  task,  and  each 
method  tells  how  to  decompose  some  compound  task  into  a  set  of  partially  ordered 
subtasks. 

2  Here,  we  assume  that  a  compound  Web  Service  always  has  a  complete  decomposition 
bottoming  out  in  atomic  processes.  Such  a  composite  process  is  executable. 
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Definition  1  (Operator)  A  SHOP2  operator  is  an  expression  of  the  form  (h(lf) 
Pre  Del  Add)  where 

•  h(lf)  is  a  primitive  task  with  a  list  of  input  parameters  IT 

•  Pre  represents  the  operator’s  preconditions 

•  Del  represents  the  operator’s  delete  list  which  includes  the  list  of  things  that  will 
become  false  after  operator’s  execution. 

•  Add  represents  the  operator’s  add  list  which  includes  the  list  of  things  that  will 
become  true  after  operator ’s  execution. 

The  expressivity  of  SHOP2  preconditions  and  effects  are  similar  to  those  found  in 
Planning  Domain  Definition  Language  (PDDL)  [7].  Precondition  contains  logical 
atoms  with  variables  that  are  either  defined  in  h  or  existentially  quantified.  Logical 
atoms  can  be  combined  using  the  logical  connectives  such  as  conjunction,  disjunc¬ 
tion,  negation,  implication  and  universal  quantification.  Add  and  Del  lists  are  gen¬ 
erally  defined  to  be  a  conjunction  of  logical  atoms  but  conditional  expressions  and 
quantified  expressions  can  also  be  used. 

Definition  2  (Method)  A  SHOP2  method  is  an  expression  of  the  form  ( h(lT )  Pre  i 
Tj  Prc-2  T-2  . . .)  where 


•  h(l7)  is  a  compound  task  with  a  list  of  input  parameters  if 

•  Each  Prei  is  a  precondition  expression 

•  Each  Tj  is  a  partially  ordered  set  of  subtasks. 

The  meaning  of  this  is  analogous  to  a  conditional  expression:  it  tells  SHOP2  that 
if  Prei  is  satisfied  then  Tx  should  be  used,  otherwise  if  Pre2  is  satisfied  then  T2 
should  be  used,  and  so  forth.  A  task  list  is  simply  a  list  of  tasks  that  tells  how  this 
compound  task  will  be  decomposed  into  subtasks.  Tasks  in  the  list  can  be  primitive 
or  compound  and  a  task  list  can  be  defined  as  ordered  or  unordered. 

In  addition  to  the  usual  logical  atoms,  preconditions  of  SHOP2  methods  and  op¬ 
erators  may  also  contain  calls  to  external  programs  and  assignments  to  variables. 
These  are  useful  for  integrating  planning  with  queries  to  information  sources  on  the 
Web.  For  example,  the  following  expression 

(assign  v  (call  ft  it2...  tn)) 

will  bind  the  variable  symbol  v  with  the  result  of  calling  external  procedure  /  with 
arguments  ti  t2  . . .  tn. 

Definition  3  (Planning  Problem)  A  planning  problem  for  SHOP2  is  a  triple  (S, 
T,  D),  where  S  is  initial  state,  T  is  a  task  list,  and  D  is  a  domain  description.  By 
taking  (S,  T,  D)  as  input,  SHOP2  will  return  a  plan  P  =  (piP2---Pn),  that  is,  a 
sequence  of  instantiated  operators  that  will  achieve  T  from  S  in  D. 
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4  Why  HTN  Planning  is  Suitable  for  Web  Service  Composition 


There  is  a  clear  point  where  the  composition  as  planning  and  composition  as  build¬ 
ing  up,  i.e.,  “composing”,  CompositeProcesses  intersect:  when  the  plan  itself  is 
a  CompositeProcess.  This  is  always  trivially  the  case  as  a  standard  SHOP2  plan 
is  a  sequence  of  operators.  Furthermore,  it  is  straightforward  to  extend  SHOP2 
to  generate  conditional  plans  which  begin  to  look  like  more  interesting  Compos¬ 
iteProcesses.  However,  the  generation  of  CompositeProcesses  by  planning  is  better 
viewed  as  the  specialization  of  prewritten  CompositeProcesses  than  the  authoring 
of  complex,  entirely  novel  programs. 

There  are  several  ways  in  which  the  HTN  approach  is  promising  for  service  com¬ 
position: 

•  HTN  encourages  modularity.  Methods  can  be  written  without  consideration  of 
how  its  subtasks  will  decompose  or  what  compound  tasks  it  decomposes.  The 
method  author  is  encouraged  to  focus  on  the  particular  level  of  decomposition  at 
hand. 

•  This  modularity  fits  in  well  with  Web  Services.  Methods  correspond  to  recur¬ 
sively  composable  workflows.  These  workflows  can  come  from  diverse  indepen¬ 
dent  sources  and  then  integrated  by  the  planner  to  produce  situation  specific, 
instantiated  workflows. 

•  Since  the  planner  considers  the  entire  execution  path,  it  has  opportunities  to  mini¬ 
mize  various  sorts  of  failures  or  costs.  Most  obviously,  if  the  planner  finds  a  plan, 
one  knows  that  the  top  level  task  is  achievable  with  the  resources  at  hand.  If  the 
granularity  of  the  services  is  large  enough  then  it  can  be  considerably  easier  for 
a  human  being  to  inspect  and  understand  the  plan. 

•  HTN  planning  scales  well  to  large  numbers  of  methods  and  operators. 

•  Some  HTN  planners  (e.g.,  SHOP2)  support  complex  precondition  reasoning,  and 
even  the  evaluation  of  arbitrary  code  at  plan  time.  These  features  make  it  straight¬ 
forward  to,  integrate  existing  knowledge  bases  on  the  Semantic  Web  as  well  as 
the  information  supplying  Web  Services. 

•  HTN  planning  provides  natural  places  for  human  intervention  at  plan  time.  The 
two  obvious  examples  are  first,  that  in  preconditions,  a  code  or  service  call  can 
query  a  person  for  special  input,  and  second,  if  the  planner  hits  a  point  where  it 
cannot  continue  decomposition,  it  can  request  a  decomposition  of  that  step  from 
another  person,  or  even  a  software  agent.  3 


3  For  example,  the  HiCAP  [8]  system  employed  SHOP  as  a  component  of  a  mixed  initia¬ 
tive  system. 
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5  From  OWL-S  to  SHOP2 


The  execution  of  an  atomic  process  is  a  call  to  the  corresponding  Web  accessible 
program  with  its  input  parameters  instantiated. 4  The  execution  of  a  composite  pro¬ 
cess  ultimately  consists  in  the  execution  of  a  collection  of  specific  atomic  processes. 
Instead  of  directly  executing  the  composite  process  as  a  program  on  an  OWL-S  in¬ 
terpreter,  we  can  treat  the  composite  process  as  specification  for  how  to  compose 
a  sequence  of  atomic  process  executions.  In  this  section,  we  will  show  how  to  en¬ 
code  a  composite  process  composition  problem  as  a  SHOP2  planning  problem,  so 
SHOP2  can  be  used  with  OWL-S  Web  Services  descriptions  to  automatically  gen¬ 
erate  a  composition  of  Web  services  calls. 


5. 1  Encoding  OWL-S  Process  Models  as  SHOP2  Domains 


In  this  section,  we  introduce  an  algorithm  for  translating  a  collection  of  OWL- 
S  process  models  K  into  a  SHOP2  domain  D.  In  our  translation,  we  make  the 
following  assumption: 

Assumption  1  Given  a  collection  of  OWL-S  process  models  K  =  { I\\ .  K2l . . . ,  Kn}, 
we  assume: 

•  All  atomic  processes  defined  in  K  can  either  have  effects  or  outputs,  but  not 
both.  According  to  the  situation  calculus  based  semantics  of  OWL-S  [9],  outputs 
characterize  knowledge  effects  of  executing  Web  Services  and  effects  charac¬ 
terize  physical  effects  for  executing  Web  services.  An  atomic  process  with  only 
outputs  models  a  strictly  information-providing  Web  Service.  And  an  atomic  pro¬ 
cess  with  only  effects  models  a  world- altering  Web  Service.  In  general,  we  don’t 
want  to  actually  affect  the  world  during  planning.  However,  we  do  want  to  gather 
certain  information  from  information-providing  Web  Services,  which  entails  ex¬ 
ecuting  them  at  plan  time.  To  enable  information  gathering  from  Web  Services 
at  planning  time,  we  require  that  the  atomic  processes  to  be  either  exclusively 
information-providing  or  exclusively  world-altering. 

•  There  is  no  composite  process  in  K  with  OWL-S ’s  Split  and  Split+Join  con¬ 
trol  constructs.  SHOP2  currently  does  not  handle  concurrency.  Therefore  in  our 
translation,  we  only  consider  OWL-S  process  models  that  have  no  composite 
process  using  Split  and  Split+Join  control  construct.  We  also  assume  only  a 
non-concurrent  interpretation  of  Unordered  (as  permitted  by  OWL-S).  We  in¬ 
tend  to  address  how  to  extend  SHOP2  to  handle  concurrency  in  the  future  work. 


1  Here,  we  assume  that  before  the  execution  of  an  atomic  process  the  preconditions  for 
executing  the  atomic  process  have  been  satisfied. 


8 


We  encode  a  collection  of  OWL-S  process  definitions  K  into  a  SHOP2  domain  D 
as  follows: 

•  For  each  atomic  process  with  effects  in  K,  we  encode  it  as  a  SHOP2  operator 
that  simulates  the  effects  of  the  world- altering  Web  Service. 

•  For  each  atomic  process  with  output  in  K,  we  encode  it  as  a  SHOP2  operator 
whose  precondition  include  a  call  to  the  information-providing  Web  Service. 

•  For  each  simple  or  composite  process  in  K,  we  encode  it  as  one  or  more  SHOP2 
methods.  These  methods  will  tell  how  to  decompose  an  HTN  task  that  represents 
the  simple  or  composite  process. 

The  following  algorithm  shows  how  to  translate  an  OWL-S  definition  of  an  atomic 
process  with  only  effects  into  a  SHOP2  operator.  5 

TRANSLATE-ATOMIC-PROCESS-EFFECT(Q) 

Input:  a  OWL-S  definition  Q  of  an  atomic  process  A  with  only  effects. 

Output:  a  SHOP2  operator  O. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  Am  Q 

(2)  Pre  =  conjunct  of  all  preconditions  of  A,  as  defined  in  Q 

(3)  Add  =  collection  of  all  positive  effects  of  A,  as  defined  in  Q 

(4)  Del  =  collection  of  all  negative  effects  of  A,  as  defined  in  Q 

(5)  Return  O  =  (A(lf)  Pre  Del  Add) 

The  above  algorithm  translates  each  atomic  OWL-S  definition  into  a  SHOP2  oper¬ 
ator  that  will  simulate  the  effects  of  a  world- altering  Web  Service  by  changing  its 
local  state  via  an  operator.  Such  Web  Services  will  never  be  executed  at  planning 
time,  for  obvious  reasons. 

The  following  algorithm  shows  how  to  translate  a  OWL-S  definition  of  an  atomic 
process  with  only  outputs  into  a  SHOP2  operator. 

TRANSLATE-ATOMIC-PROCESS-OUTPUT(Q) 

Input:  a  OWL-S  definition  Q  of  an  atomic  process  A  with  only  outputs. 

Output:  a  SHOP2  operator  O. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  A  as  in  Q 

(2)  Pre  =  a  conjunct  of  all  the  preconditions  of  A,  as  defined  in  Q,  plus  one  more 
precondition  of  the  form  (assign  y  (call  Monitor  A  if)),  where  Monitor  is  a 
procedure  which  will  handle  SHOP2’s  call  to  Web  services 

(3)  Add  =  y 


5  Conditional  effects  can  be  easily  encoded  into  SHOP2  operators.  Here,  for  simplicity, 
we  assume  that  effects  (and  outputs)  are  not  conditional. 
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(4)  Del  =  0 

(5)  Return  O  =  ( A(lf )  Pre  Del  Add ) 

The  above  algorithm  translates  each  atomic  OWL-S  definition  into  a  SHOP2  op¬ 
erator  that  will  call  the  information-providing  Web  service  in  its  precondition.  In 
this  way,  the  information-providing  Web  Service  is  executed  during  the  planning 
process.  The  operator  for  these  atomic  processes  are  entirely  “book-keeping”,  thus 
none  of  these  operators  will  appear  in  the  final  plan. 

The  following  algorithm  shows  how  to  translate  a  OWL-S  definition  of  a  simple 
process  into  SHOP2  method(s). 

TRANSLATE-SlMPLE-PROCESS((3) 

Input:  a  OWL-S  definition  Q  of  a  simple  process  S. 

Output:  a  collection  of  SHOP2  methods  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  S  as  in  Q 

(2)  Pre  =  conjunct  of  all  preconditions  of  S  as  defined  in  Q 

(3)  (£»i, . . . ,  bm)  =  the  list  of  atomic  and  composite  processes  that  realizes  or  col¬ 
lapse  into  S  as  defined  in  Q. 

(4)  for  i  =  1,  . . . ,  m 

•  Mi  =  (S(lf)  Pre  bd 

(5)  return  M  ={M l5  . . . ,  Mm} 

The  following  algorithm  shows  how  to  translate  a  OWL-S  definition  of  a  composite 
process  with  Sequence  control  construct  into  a  SHOP2  method. 

TRANSLATE-Sequence-PROCESS(Q) 

Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  Sequence  control 
construct. 

Output:  a  SHOP2  method  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  Pre  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(3)  B  =  Sequence  control  construct  of  C  as  defined  in  Q 

(4)  bm)  -  the  sequence  of  component  processes  of  B  as  defined  in  Q 

(5)  T  =  ordered  task  list  of  (&!,...  bm) 

(6)  Return  M  =  ( C(lf )  Pre  T) 

The  following  algorithm  shows  how  to  translate  a  OWL-S  definition  of  a  composite 
process  with  If-Then-Else  control  construct  into  a  SHOP2  method. 

TRANSLATE-If-Then-Else-PROCESS((3) 
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Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  If-Then-Else  control 
construct. 

Output:  a  SHOP2  method  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  7 Tif  =  conditions  for  If  as  defined  in  Q 

(3)  Pre i  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q  and  ^ r.j/ 

(4)  Pre 2  is  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(5)  bi  =  process  for  Then  as  defined  in  Q 

(6)  b2  =  process  for  Else  as  defined  in  Q 

(7)  Return  M  =  ( C(lf )  Pre i  bi  Pre2  b2) 

The  following  algorithm  translates  a  OWL-S  definition  of  a  composite  process  with 
Repeat- While  control  construct  into  SHOP2  methods. 

TRANSLATE-Repeat-While-PROCESS(Q) 

Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  Repeat- While  con¬ 
trol  construct. 

Output:  a  collection  of  SHOP2  methods  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  iTwhiie  =  conditions  for  While  as  defined  in  0 

(3)  Pre  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(4)  bi  =  process  for  Repeat  as  defined  in  Q 

(5)  Mx  =(C(lf  )  Pre  C\(lf  )) 

(6)  M2  =  (Ci(lf)  7 iWhile  (6i Cj(7?))  0  0) 

(7)  Return  M  =  {Mi,  M2} 

Note  that  M2  method  definition  has  two  condition-task  list  pairs.  The  first  condition 
and  task  list  pair  ensures  that  the  process  inside  the  loop  is  iterated  as  long  as  the 
condition  is  true.  When  this  condition  becomes  false,  SHOP2  will  check  the  second 
condition  which  is  empty  (denoted  by  0)  thus  always  true.  The  task  list  for  this 
condition  is  also  empty  so  nothing  will  be  added  to  the  resulting  plan.  This  second 
pair  is  just  needed  to  make  sure  that  plan  will  not  fail  when  the  loop  condition 
becomes  false. 

The  following  algorithm  translates  a  OWL-S  definition  of  a  composite  process  with 
Repeat-Until  control  construct  into  SHOP2  methods. 

TRANSLATE-Repeat-Util-PROCESS(Q) 

Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  Repeat-Until  control 
construct. 

Output:  a  collection  of  SHOP2  methods  M. 

Procedure: 
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(1)  if  -  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  7 x Untii  -  conditions  for  Until  as  defined  in  Q 

(3)  Pre  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(4)  b\  =  process  for  Repeat  as  defined  in  Q 

(5)  Mi  =  (C(lf)  Pre  Ci(lf)) 

(6)  M2  =  (Ci(lf)  (not(nUntii))  (biCi(lf))  0  0) 

(7)  Return  M  =  {Mi,  M2} 

The  following  algorithm  translates  a  OWL-S  definition  of  a  composite  process  with 
Choice  control  construct  into  a  collection  of  SHOP2  methods. 

TRANSLATE-Choice-PROCESS(Q) 

Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  Choice  control  con¬ 
struct. 

Output:  a  collection  of  SHOP2  methods  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  Pre  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(3)  B  =  Choice  control  construct  of  C  as  defined  in  Q 

(4)  bm)  =  the  bag  of  component  processes  of  B  as  defined  in  Q 

(5)  for  i  =  1,  . . . ,  m 

•  Mi  =  (C(lf)  Pre  bf) 

(6)  return  M  ={Mi,  . . . ,  Mm } 

The  following  algorithm  translates  a  OWL-S  definition  of  a  composite  process  with 
Unordered  control  construct  into  a  SHOP2  method. 

TRANSLATE-Unordered-PROCESS(Q) 

Input:  a  OWL-S  definition  Q  of  a  composite  process  C  with  Unordered  control 
construct. 

Output:  a  SHOP2  method  M. 

Procedure: 

(1)  if  =  the  list  of  input  parameters  defined  for  C  as  in  Q 

(2)  Pre  =  conjunct  of  all  preconditions  of  C  as  defined  in  Q 

(3)  B  =  Unordered  control  construct  of  C  as  defined  in  Q 

(4)  (bi, ,  bm)  -  the  bag  of  component  processes  of  B  as  defined  in  Q 

(5)  T  =  unordered  task  list  of  (bi, . . .  bm) 

(6)  Return  M  =  (C(lf)  Pre  T ) 

The  following  algorithm  translates  a  collection  of  OWL-S  process  models  into  a 
SHOP2  domain. 

TRANSLATE-PROCESS-MODEL(A ) 

Input:  a  collection  of  OWL-S  process  models  K. 
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Output:  a  SHOP2  domain  D. 

Procedure: 

(1)  D  =  0 

(2)  For  each  atomic  process  definition  Q  in  K 

•  If  this  atomic  process  has  only  outputs 

•  O  =  TRANSLATE- ATOMIC-PROCESS-OUTPUT(Q) 

•  If  this  atomic  process  has  only  effects 

•  O  =  TRANSLATE-ATOMIC-PROCESS-EFFECT(Q) 

•  add  O  to  D 

(3)  For  each  simple  process  definition  Q  in  K 

•  M  =  TRANSLATE-SIMPLE-PROCESS(Q) 

•  add  M  to  D 

(4)  For  each  composite  process  definition  Q  in  K 

•  If  the  process  has  a  Sequence  control  construct 

•  M  =  TRANSLATE-Sequence-PROCESS(Q) 

•  If  the  process  has  a  If-Then-Else  control  construct 

•  M  =  TRANSLATE-If-Then-Else-PROCESS(Q) 

•  If  the  process  has  a  Choice  control  construct 

■  M  =  TRANSLATE-Choice-PROCES  S(Q) 

•  If  the  process  has  a  Repeat- While  control  construct 

■  M  =  TRAN  S  L  ATE-Repe  at- While-PROCES  S(Q) 

•  If  the  process  has  a  Repeat-Until  control  construct 

■  M  =  TRANSLATE-Repeat-Until-PROCESS(Q) 

•  If  the  process  has  a  Unordered  control  construct 

■  M  =  TRANSLATE-Unordered-PROCES  S(Q) 

•  add  M  to  D 

(5)  Return  D 

To  keep  the  above  pseudocode  simple,  we  did  not  specify  the  recursive  translations 
within  a  composite  process.  E.g.,  What  happens  if  we  have  a  Sequence  of  If-Then- 
Else  or  further  nestings?  Our  way  for  handling  this  problem  is  to  treat  each  control 
construct  within  a  composite  process  as  a  composite  process.  For  above  example, 
in  our  translation,  we  will  have  a  SHOP2  method  for  the  composite  process  with 
Sequence  control  construct  and  a  method  for  each  nested  If-Then-Else  control 
construct. 

Also  we  did  not  explicitly  describe  how  our  algorithm  handles  processes  with 
dataflow  specification.  In  OWL-S,  a  composite  process  can  specify  that  an  output 
of  a  composite  process  is  equal  to  an  output  of  one  of  its  subprocesses  whenever  the 
composite  process  is  instantiated.  Also,  for  a  composite  process  with  a  Sequence 
control  construct,  one  can  specify  that  the  output  of  one  subprocess  is  an  input  to 
another  subprocesses.  SHOP2  does  not  have  the  concept  of  an  output  and  we  sim¬ 
ply  treat  outputs  as  knowledge  effects.  The  output  results  of  a  service  are  recorded 
in  the  current  state  using  a  special  predicate  and  by  assigning  a  unique  number  to 
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each  instance  of  a  SHOP2  domain’s  methods  and  operators.  The  predicate  ( Output 
Instance  Value )  indicates  a  method  or  operator  instance  Instance  has  the  value 
Value  for  the  particular  output  Output. 

The  other  aspect  of  the  translation  we  omitted  in  the  algorithm  is  the  translation  of 
preconditions  and  effects.  The  current  OWL-S  specification  (version  1.0)  does  not 
have  a  concrete  syntax  for  precondition  specification.  OWL-S  1 . 1  will  support  the 
description  of  the  preconditions  and  effects  of  services  using  OWL  statements  with 
variables  similar  to  atoms  in  Semantic  Web  Rule  Language  (SWRL).  These  atoms 
will  be  combined  with  logical  connectives  that  are  already  supported  in  SHOP2. 
The  translation  of  such  expressions  would  be  straight-forward  but  it  is  also  impor¬ 
tant  to  preserve  the  semantics  of  OWL  (see  Section  7.1). 


5.2  Encoding  OWL-S  Web  Sendees  Composition  Problem  as  SHOP2  Planning 
Problem 


Narayanan  and  Mcllraith  [9]  give  a  formal  semantics  for  OWL-S  in  terms  of  the 
situation  calculus  [10]  and  Golog  [11].  The  situation  calculus  in  a  first-order  lan¬ 
guage  for  reasoning  about  action  and  change.  In  the  situation  calculus,  the  state  of 
the  world  is  described  by  functions  and  relations  (fluents)  relativized  to  a  situation 
s,  e.g.,  f(x ,  s).  The  function  do(a ,  s)  maps  a  situation  s  and  an  action  a  into  a  new 
situation.  A  situation  is  simply  a  history  of  the  primitive  actions  performed  from  an 
initial,  distinguished  situation  So- 

Golog  is  a  high-level  logic  programming  language  based  on  the  situation  calculus, 
that  enables  the  represenation  of  complex  actions.  It  builds  on  top  of  the  situation 
calculus  by  providing  a  set  of  extralogical  constructs  (Figure  1)  for  assembling 
primitive  actions,  defined  in  the  situation  calculus,  into  complex  actions  that  col¬ 
lectively  comprise  a  program,  5.  Given  a  domain  theory,  D  and  a  Golog  program 
5,  program  execution  must  find  a  sequence  a,  such  that  D  f=  Do(8 ,  S0,  do(a ,  S0)). 

Do(8,  S0,  do(a ,  S0))  denotes  that  Golog  program  5  starting  at  .5'0  will  legally  termi¬ 
nate  in  situation  do(a,  S0 ))  where  do(a ,  £0))  abbreviates  do(an,  do(an- 1, . . . ,  do(ai,  S0 )). 
Thus,  an  are  the  actions  that  realize  Golog  program  Delta,  starting  in  the 

initial  situation,  So. 

The  semantics  given  in  [9]  and  [12]  maps  an  OWL-S  process  to  a  Golog  program 
where  atomic  processes  in  OWL-S  are  mapped  to  primitive  actions  in  Golog  and 
composite  processes  in  OWL-S  are  mapped  to  corresponding  complex  Golog  ac¬ 
tions.  Using  these  semantics,  we  can  define  the  OWL-S  service  composition  prob¬ 
lem  as  follows: 

Definition  4  (OWL-S  Service  Composition)  Let  K  =  {K\,  I<2,  . . .,  Km}  be  a 

collection  of  OWL-S  process  models  satisfying  Assumption  1  (from  section  5.1),  C 
be  a  possibly  composite  process  defined  in  K,  S0  be  the  initial  state,  and  P  = 


14 


a  -  primitive  action 
81,82-  sequence 
condl  -  test 

Si  8  2  -  nonde  termini  Stic  choice  of  actions 
8*  -  nondeterministic  iteration 
if  concl  then  Si  else  S2  endlf  -  conditional 
while  cond  do  S  endWhile  -  while  loop 


Fig.  1.  A  subset  of  Golog  constructs  to  create  complex  actions  that  are  relevant  to  OWL-S 
constructs. 

ip  1 .  p2  ,  . . .  ,pn)  be  a  sequence  of  atomic  processes  defined  in  K.  Then  P  is  a  com¬ 
position  for  C  with  respect  to  K  in  So  iff  in  action  theory,  we  can  prove: 

£  |=  Do(8c,  S0,do(a,  S0))) 


where 

•  £  is  the  axiomatization  of  K  and  So  as  defined  in  action  theory. 

•  Sc  is  the  complex  action  defined  for  C  as  defined  in  action  theory 

•  a,  is  the  primitive  action  defined  for  pt  as  defined  in  action  theory 

Note  that,  this  definition  is  for  offline  planning,  i.e.  there  is  no  execution  of  information¬ 
providing  Web  Services  during  planning.  This  definition  assumes  that  the  initial 
state  contains  the  complete  information  for  the  domain.  In  reality,  this  is  not  the 
case  and  we  interleave  the  execution  of  information-providing  services  with  the 
simulation  of  world-altering  ones  to  complete  the  information  in  the  initial  state. 
Information  gathering  is  done  with  respect  to  the  the  initial  state  so  the  planning 
process  would  yield  the  same  results  if  all  the  information-providing  Web  Services 
were  executed  first  and  then  planning  was  done.  There  are  some  conditions  (simi¬ 
lar  to  IRP  assumption  [12])  that  needs  to  hold  in  order  to  extend  this  theorem  for 
interleaved  execution.  We  will  discuss  these  conditions  at  the  end  of  this  section. 

We  will  now  prove  that  the  plans  SHOP2  finds  for  the  OWL-S  service  composition 
problem  are  equivalent  to  the  action  sequences  found  in  situation  calculus.  We  will 
use  the  simplified  version  of  SHOP2  algorithm  (Figure  2)  during  the  proof.  Since 
Golog  does  not  provide  an  Unordered  construct  we  will  not  consider  this  construct 
in  our  proof  and  in  the  SHOP2  algorithm  we  have  omitted  the  details  related  to 
unordered  tasks.  It  is  possible  to  define  Unordered  construct  in  ConGolog  (Concur¬ 
rent  Golog)  [13]  which  is  an  extension  to  Golog  that  allows  concurrent  execution. 

But  since  SHOP2  does  not  allow  concurrent  processes  we  cannot  use  this  exten¬ 
sion.  Also  note  that  in  the  original  Golog  formalism  complex  actions  are  defined  as 
macro  definitions  [11]  so  complex  actions  do  not  have  preconditions.  In  our  proof, 
we  will  show  the  correspondence  to  the  original  Golog  approach  and  assume  that 
in  the  given  OWL-S  process  model  only  atomic  processes  have  preconditions. 
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1  procedure  SHOP2(s,  T,  D) 

2  if  T  is  empty  then  return  empty  plan 

3  Let  t  be  the  first  task  in  T 

4  if  t  is  a  primitive  task  then 

5  Find  an  operator  o  =  (h  Pre  Add  Del )  in  D  such  that 

h  unifies  with  t  and  s  satisfies  Pre 

6  if  no  such  o  exists  then  return  failure 

7  Let  s'  be  s  after  deleting  Del  and  adding  Add 

8  Let  T'  be  T  after  removing  t 

9  return  [o,  SHOP2(s',  T',  D)] 

10  else  if  t  is  a  composite  task 

1 1  Find  a  method  m  =  (h  Pre \  Ti  Pre2  T2  . . .)  in  D  such  that 

h  unifies  with  t 

12  Find  the  task  list  7)  such  that 

s  satisfies  I're,,  and  does  not  satisfy  Prek,  k  <  i 

13  if  no  such  T,  exists  then  return  failure 

14  Let  T'  be  T  after  removing  t 

and  adding  all  the  elements  in  Tj  at  the  beginning 

15  return  SHOP2(s',  T',  D) 

16  end  if 

17  end  SHOP2 

Fig.  2.  A  simplified  version  of  the  SHOP2  planning  procedure. 

Theorem  5  Let  K  =  { I\\ .  K2, . . . ,  Km}  be  a  collection  of  OWL-S process  models 
satisfying  Assumption  1  ( from  section  5.1),  C  be  a  possibly  composite  process  de¬ 
fined  in  K,  5'o  be  the  initial  state,  and  P  =  (p\,p2, . .  ■  ,pn)  be  a  sequence  of  atomic 
processes  defined  in  K.  Let  D  =  TRANSLATE-PROCESS-MODEL( K ).  Then  P  is  a 
composition  for  C  with  respect  to  K  in  S0  iff  P  is  a  plan  for  planning  problem  (So, 
Me,  D)  where  Me  is  the  SHOP  translation  for  process  C. 


PROOF.  Before  giving  the  proof  we  should  note  that  there  is  a  representational 
difference  between  how  SHOP2  and  situation  calculus  describes  the  state  of  the 
world.  SHOP2  represents  state  by  a  set  of  ground  atoms  whereas  in  the  situation 
calculus,  the  state  of  the  world  is  described  by  relations  (fluents)  relativized  to  a 
situation.  For  example,  f(x)  is  true  at  some  point  in  the  planning  process  when  that 
atom  occurs  in  SHOP2’s  “state”  (e.g.,  the  set  of  ground  atoms).  In  the  situation  cal¬ 
culus,  truth  value  for  that  relation  is  relative  to  a  specific  situation  argument,  e.g., 
f(x,  s ).  The  changes  to  the  state  in  SHOP2  is  done  by  adding  or  deleting  atoms 
from  the  state  whereas  situation  calculus  defines  successor  state  axioms  to  define 
the  truth  values  for  the  fluents  in  different  situations.  Apart  from  this  representa¬ 
tional  difference,  there  is  an  equivalence  between  SHOP2  state  and  situations,  e.g. 
f(x)  is  true  in  the  initial  state  of  SHOP2  iff  f(x,  S0)  is  true  in  situation  calculus. 
Applying  the  effects  of  an  operator  will  also  preserve  this  equivalence.  It  is  easy 
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to  verify  that  the  truth  value  for  the  predicate  f(x)  after  applying  the  effects  of  an 
operator  will  be  equal  to  the  truth  value  of  f(x,  do(a ,  s))  when  a  is  the  correspond¬ 
ing  situation  calculus  action  and  the  starting  states  are  equivalent.  In  general,  when 
the  same  sequence  of  actions/operators  are  applied  to  a  situation/state,  the  state  of 
the  world  in  the  final  situation/state  will  be  the  same.  Throughout  the  proof,  we  will 
use  this  equivalence  and  use  the  same  name  to  denote  world  states  in  both  notations 
when  the  meaning  is  clear.  The  proof  of  the  theorem  is  by  induction: 

Hypothesis  For  a  given  OWL-S  process  C,  P  is  a  plan  for  the  planning  problem 
(S0,  Mc,  D )  iff  E  |=  Do(5c ,  S0,  do(a,  S0)))  where  a  —  [a-i,  a2 , . . .]  is  the  sequence 
of  primitive  actions  in  situation  calculus  that  corresponds  to  the  sequence  of  SHOP2 
operators  in  P. 

Base  Case  Suppose  A  is  an  atomic  OWL-S  process  and  a  is  the  corresponding 
primitive  action  in  situation  calculus  and  oa  is  the  corresponding  SHOP2  operator. 
Then  in  Golog  it  is  defined  that 

Do(a ,  s,  s')  =  Poss(a ,  s)  A  s'  =  do(a,  s ) 

It  means  when  the  preconditions  for  the  process  is  satisfied  with  respect  to  situation 
s  then  the  primitive  action  sequence  we  will  get  for  this  simple  program  will  have 
only  one  element,  namely  a  —  [a] .  As  seen  in  line  9  of  SHOP2  algorithm,  the  plan 
for  a  primitive  task  will  return  the  plan  that  includes  the  operator  instance  when  the 
preconditions  of  that  operator  are  satisfied  (the  recursive  call  will  return  empty  list 
as  there  are  no  more  tasks  in  the  list).  Thus,  the  plan  returned  by  SHOP2  is  [ o  a  ] 
which  is  equivalent  to  the  situation  calculus  result. 

Inductive  Step  We  will  do  a  case  by  case  analysis  for  each  of  the  control  constructs 
in  the  process  model  to  show  that  our  translation  and  resulting  plans  SHOP2  finds 
are  correct. 

Choice  Suppose  C  is  a  composite  OWL-S  process  defined  as  a  Choice  of  two  6 
other  processes  Cj  and  C2.  The  SHOP2  translation  for  C  will  yield  two  methods 
Mi  =  ((7  0  MCl)  and  M2  =  ((7  0  Mc.2).  Note  that  the  SHOP2  methods  have  no  pre¬ 
conditions  (0  is  used  for  preconditions)  because  we  have  assumed  that  composite 
processes  cannot  have  preconditions.  Corresponding  Golog  program  for  <7  is  <5c>  = 
5ci  |  dC2  and  the  semantics  is  defined  as 

Do(8Cl\8C2,s,s')  =  Do(SCl,s,  s')  V  Do(8c2,s,  s') 

The  disjunction  means  any  a  that  is  a  valid  action  sequence  for  either  5Cl  or  SC2 
will  also  be  a  valid  sequence  for  Sc-  From  our  hypothesis  we  know  for  each  action 
sequence  a  that  satisfies  6Cl  (or  dc,2 )  we  have  a  valid  SHOP2  plan  PCl  (or  Pc2). 


6  Golog  choice  operator  |  is  defined  for  two  operands.  A  choice  of  more  operands  could 
be  done  by  nested  |  operators  which  would  not  effect  our  proof  here 
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The  nonde  termini  Stic  choice  in  SHOP2  algorithm  (line  1 1)  shows  that  when  a  plan 
is  being  sought  for  C,  the  solution  for  any  matching  method  instance,  in  this  case 
Mi  and  M2,  will  be  returned  as  a  result.  This  ensures  that  when  SHOP2  is  asked  to 
find  all  the  plans  for  C,  both  Pc\  and  Pc2  will  be  returned  proving  the  equivalence 
to  the  answer  in  situation  calculus. 

Sequence  Suppose  C  is  a  composite  OWL-S  process  defined  as  a  Sequence  of  two 
other  processes  C\  and  C2.  The  SHOP2  translation  for  C  will  yield  one  method 
Me  =  (C  0  (Me i  Me2))-  Corresponding  Golog  program  for  C  is  5c  =  (V;,  ;  5c2  and 
the  semantics  is  defined  as 


Do(SCl-1Sc2,s,s')  =  (3s*)(Do(SCl,s,s*)  A  Do(6C2,s*,s')) 

Suppose  that  situation  s*  represents  a  history  of  the  action  sequence  a[.  If  the  action 
sequence  recorded  between  situations  s*  and  s'  is  a2  then  the  final  situation  s'  repre¬ 
sents  the  concatenated  sequence  a  =[ai,  a2\.  Calling  SHOP2(s,  MCl,  D)  will  return 
Pc i  and  from  our  hypothesis  we  know  that  it  is  equivalent  to  the  action  sequence 
d[.  We  also  know  that  calling  SHOP2(s*,  Mc,2 ,  D)  will  return  a  plan  Pc2  that  is 
equivalent  to  the  action  sequence  d[.  SHOP2  algorithm  shows  that  (line  14)  when 
a  task  (in  this  case  Me)  is  removed  from  the  input  task  network  T,  it  is  replaced 
with  its  sub-elements  (in  this  case  Me1  and  Mc2).  The  tasks  to  solve  are  selected 
from  T  in  the  order  they  were  added  (line  3)  so  the  resulting  plan  for  SHOP2(s, 
Mc,  D )  will  actually  be  the  concatenation  of  PCl  and  Pc.2  which  is  equivalent  to 
the  sequence  a. 

If-Then-Else  Suppose  C  is  a  composite  OWL-S  process  defined  with  a  If-Then- 
Else  control  construct  and  cond  is  the  condition  for  the  if  statement,  C\  is  the  pro¬ 
cess  in  the  then  part  and  C2  is  the  process  in  the  else  part.  The  SHOP2  translation 
for  C  will  yield  one  method  Mc  =  (C  cond  MC]  0  Mc.2).  Corresponding  Golog  pro¬ 
gram  for  C  is  6c  =  (if  cond  then  5Cl  else  d}:2  endlf)  and  the  semantics  is  defined 
as 

Do( if  cond  then  5Cl  else  5C2  endlf,  s,  s’) 

=  Do((cond ?;  ^i)*  s>  s’)  V  Do((^cond7',  Sc2),  s,  s’) 

=  ( cond[s\  A  Do{5c1 ,  s,  s’))  V  (-> cond[s]  A  Do(5c2,  s,  s’)) 

The  expression  cond[s]  evaluates  to  true  whenever  the  fluent  cond  is  true  in  situa¬ 
tion  s.  Suppose  d\  is  the  action  sequence  for  the  situation  5Cl  and  a2  is  the  action 
sequence  for  the  situation  Sc2.  If  s  satisfies  cond  then  the  result  for  5c  will  be  d\ 
otherwise  result  will  be  ct2.  From  our  hypothesis  we  know  for  any  possible  a\  (or 
a2)  we  have  a  valid  SHOP2  plan  PCl  (or  Pc2)-  When  we  call  SHOP2(s,  Mc,  D), 
the  algorithm  will  check  the  conditions  in  the  method  definition  (line  12),  cond  and 
0  in  this  translation.  If  cond  is  satisfied  algorithm  returns  Pc1  and  otherwise  returns 
PC2  which  is  equivalent  to  the  the  result  in  situation  calculus. 

Repeat- While  Suppose  C  is  a  composite  OWL-S  process  defined  with  a  Repeat- 
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While  control  construct  and  cond  is  the  condition  for  the  while  statement  and  C\ 
is  the  process  in  the  loop  body.  As  we  have  assumed  that  composite  processes 
do  not  have  preconditions,  without  losing  generality,  we  can  simplify  the  SHOP2 
translation  to  be  Mc  =  (C  cond  (C\  C)  0  0).  Corresponding  Golog  program  for  C 
is  5c  =  (while  cond  do  5c1  endWhile)  and  the  semantics  is  defined  as 

Do(while  cond  do  Sc\  endWhile,  s,  s’)  =  Do([[(cond ?;  (i'd)]*;  ~^cond?],  s,  s’) 

This  definition  includes  the  nondeterministic  iteration  operation  *  which  has  a 
second-order  semantics  [11].  We  will  use  the  restricted  version  of  Golog  as  de¬ 
fined  in  [12]  where  the  the  iterations  has  a  limit  k.  This  restriction  eliminates  the 
problems  caused  by  unlimited  looping  and  enables  us  to  define  a  first  order  seman¬ 
tics. 

Assume  the  iteration  runs  k  times.  When  k  —  0,  the  above  formula  simplifies  to 
Do(~<cond?,  s,  s’)  which  returns  an  empty  action  sequence  in  situation  calculus. 
This  new  formula  also  implies  condition  cond  is  false  in  the  initial  situation  s. 
When  SHOP2  is  trying  to  solve  Me,  since  cond  is  false  the  algorithm  will  choose 
(line  12)  the  second  condition-task  list  pair  (note  that  the  second  condition  in  Me 
is  0  which  is  always  true).  The  second  task  list  is  0  so  SHOP2  will  return  an  empty 
plan  as  well.  Suppose  a  is  a  valid  action  sequence  for  5Cl.  From  our  hypothesis  we 
know  for  each  action  sequence  a  that  satisfies  <5ci  we  have  a  valid  SHOP2  plan  Pcx. 
In  the  general  case,  when  k  >  0,  the  Golog  formula  becomes  Do([cond ?;  (A;,  ) 1 ; 
. . .;  cond?;  (A;,  )k;  ~>cond?\,  s,  s’)  hence  the  action  sequence  will  be  [a\,  . . .,  A,]- 
Note  that  action  sequence  for  each  step  of  iteration  may  be  different,  for  example 
when  5c1  contains  nondeterministic  choices.  We  also  know  that  cond  will  be  true 
in  situations  s,  si, . . . ,  Sk-i  and  false  in  situation  Sk.  When  SHOP2  is  searching 
a  plan  for  Me,  the  first  condition  {cond)  will  evaluate  to  true  and  SHOP2  will 
chose  the  first  task  list  (C\  C).  Solving  the  first  task  C\  will  add  Pi  to  the  plan 
and  solving  second  task  C  will  recursively  continue  until  cond  fails.  Since,  initial 
states  are  equal  and  plan  prefixes  are  same,  cond  will  not  hold  after  /,  th  iteration. 
At  this  point,  algorithm  will  chose  the  second  condition-task  list  pair  (empty  task 
list)  which  will  conclude  the  recursion  and  the  plan  returned  will  be  [Pi,  . . .,  P&], 
At  each  step  of  the  iteration  we  will  have  the  equivalent  world  states  so  the  action 
sequence  at  and  plan  P,  will  be  equivalent  due  to  our  hypothesis.  Therefore,  the 
final  plan  and  the  final  action  sequence  will  be  equivalent. 

Repeat-Until  The  proof  for  this  case  will  be  very  similar  to  the  above  proof  for 
Repeat-While  construct. 


Our  proof  did  not  include  the  effects  of  executing  information-providing  services 
during  planning.  Information  gathering  during  planning  is  same  as  the  Middle 
Ground  execution  (MG)  for  sensing  actions  in  Golog  approach  [12].  In  both  cases, 
planning  starts  with  an  incomplete  initial  state  and  executing  sensing  actions  add 
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new  knowledge  to  the  state.  As  long  as  the  information  retrieved  from  the  services 
is  same,  we  would  still  have  the  equivalence  of  world  states  in  both  representations 
and  we  could  extend  the  proof  to  this  case. 

The  correctness  of  MG  depends  on  Invocation  and  Reasonable  Persistence  (IRP) 
assumption.  Intuitively,  IRP  assumption  says  that  1)  Information-providing  ser¬ 
vices  should  be  executable  in  the  initial  state,  and  2)  Information  gathered  from 
these  services  cannot  be  changed  by  external  or  subsequent  actions.  The  first  con¬ 
dition  follows  from  the  fact  that  information  gathering  is  done  with  respect  to  the 
initial  state.  Second  condition  assumes  no  external  source  will  change  the  gathered 
information  during  the  planning  process  but  also  prohibits  the  planner  do  any  ac¬ 
tion  that  will  do  so.  This  is  to  prevent  problems  such  as  this  one:  In  our  example 
domain  (see  Section  2)  a  Web  Service  is  executed  to  get  the  available  appointment 
times  from  a  hospital.  Then  planner  simulates  scheduling  an  appointment  at  one 
of  the  available  time  slots.  If  the  information-providing  service  is  executed  again 
and  available  appointment  times  (which  has  not  yet  been  changed)  are  added  to  the 
knowledge  base  then  there  would  be  a  problem  because  planner  would  be  able  to 
schedule  another  appointment  in  the  same  time  slot.  IRP  prohibits  the  second  step 
(changing  the  information  retrieved)  to  overcome  this  problem.  This  is  certainly 
very  restrictive  in  our  case  and  our  solution  is  to  prohibit  the  last  step  where  the 
same  information-providing  service  is  executed  more  than  once. 

To  establish  the  soundness  and  completeness  of  our  approach  we  have  the  following 
assumptions  about  the  information-providing  Web  Services: 

•  executable  (in  the  initial  state  with  all  parameters  grounded) 

•  terminable  (with  finite  computation) 

•  repeatable  (with  same  result  for  the  same  call  during  the  planning  process) 

We  also  assume  that  the  information  that  is  returned  from  different  Web  Services 
are  disjoint,  i.e.  no  two  services  return  the  same  information.  These  assumptions 
guarantee  that  information  gathered  can  only  be  changed  by  the  actions  planner 
simulates  and  there  is  no  way  that  this  simulated  change  will  be  undone  by  another 
information  gathering  step  as  long  as  we  execute  each  information-providing  Web 
Service  at  most  once. 

One  other  thing  to  note  is  that,  different  from  the  Golog  approach,  we  don’t  allow 
the  information-providing  services  appear  in  the  final  plan  since  our  translation 
methodology  maps  them  to  “book-keeping”  operators.  However,  this  is  just  a  style 
difference  as  in  the  Golog  approach  a  post-processing  step  is  suggested  to  find  the 
world- altering  services  for  the  execution  of  the  resulting  plan.  In  some  situations, 
it  could  still  be  valuable  to  include  the  information-providing  services  in  the  plan 
so  a  prudent  action  could  verify  if  the  information-providing  services  still  return 
same  information.  This  could  be  easily  achieved  in  our  system  by  changing  the 
TRANSLATE-ATOMIC-PROCESS-OUTPUT  procedure  to  generate  a  standard  oper- 
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Fig.  3.  System  Architecture 

ator  rather  than  a  “book-keeping”  operator  (translation  rules  for  precondition  and 
effect). 


6  Implementation 


To  realize  our  ideas,  we  started  with  an  implementation  of  a  OWL-S  to  SHOP2 
translator.  This  translator  is  a  Java  program  that  reads  in  a  collection  of  OWL- 
S  process  definitions  and  outputs  a  SHOP2  domain.  As  shown  in  the  translation 
algorithm  in  Section  5.1,  when  planning  for  any  problem  in  this  domain,  SHOP2 
will  actually  call  the  information-providing  Web  services  to  collect  information 
while  maintaining  the  ability  of  backtrack  by  merely  simulating  the  effect  of  world- 
altering  Web  services.  The  output  of  SHOP2  is  a  sequence  of  world-altering  Web 
services  calls  that  can  be  subsequently  executed. 

We  built  a  monitor  which  handles  SHOP2’s  calls  to  external  information-providing 
Web  Services  during  planning.  We  wrote  a  OWL-S  Web  Services  executor  which 
communicates  with  SOAP  based  Web  Services  described  by  OWL-S  groundings 
to  WSDL  descriptions  of  those  Web  Services.  Upon  SHOP2’s  request,  the  moni¬ 
tor  will  call  this  OWL-S  Web  Services  executor  to  execute  the  corresponding  Web 
Service.  Since  the  information-providing  services  are  always  defined  as  atomic  pro¬ 
cesses,  the  service  is  executed  by  invoking  the  WSDL  service  in  the  grounding. 
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The  monitor  also  caches  the  responses  of  the  information-providing  Web  services 
to  avoid  invoking  a  Web  Service  with  same  parameters  more  than  once  during 
planning.  This  will  save  the  network  communication  times  and  improve  planning 
efficiency,  and  establishes  the  repeatability  condition  required  for  proving  SHOP2’s 
soundness  and  completeness.  Also  information  can  only  be  added  into  the  current 
state  if  it  has  not  been  changed  by  the  planner.  We  assume  that  the  cached  infor¬ 
mation  will  not  be  changed  by  other  agents  during  planning  and  we  will  generalize 
this  in  our  future  work. 

We  also  built  a  SHOP2  to  OWL-S  plan  converter,  which  will  convert  the  plan  pro¬ 
duced  by  SHOP2  to  OWL-S  format  which  can  be  directly  executed  by  the  OWL-S 
executor. 

We  ran  our  scenario  from  Section  2  on  this  system.  In  doing  so: 

•  Our  system  communicated  with  real  Web  Services.  Unfortunately,  the  current 
Web  Services  available  on  the  Web  have  only  WSDL  descriptions  without  any 
semantic  mark-up.  Therefore,  we  created  OWL-S  mark-up  for  the  WSDL  de¬ 
scriptions  of  these  online  services.  For  some  services  it  was  necessary  to  create 
even  the  WSDL  description,  e.g.  for  CVS  Online  Pharmacy  Store.  It  was  not 
possible  to  use  real  services  for  some  of  the  services  either  because  none  was 
available  as  Web  Services,  e.g.  a  doctor’s  agent  providing  the  patient’s  prescrip¬ 
tion,  or  it  was  infeasible  to  use  a  real  Web  Service  for  the  demo,  e.g.  making  an 
appointment  with  a  doctor  each  time  the  program  is  executed.  For  these  services, 
we  implemented  Web  Services  to  simulate  these  functionalities. 

•  We  built  Web  Services  that  allow  the  access  to  user’s  personal  information  sources. 
For  example,  it  is  necessary  to  leam  the  user’s  schedule  to  be  able  to  generate 
a  plan  for  the  example  task  in  our  demo.  It  is  possible  to  get  this  information 
from  the  sources  available  on  the  user’s  machine  such  as  a  Personal  Information 
Manager  like  Microsoft’s  Outlook.  We  have  implemented  “local”  SOAP  based 
services  that  will  retrieve  this  kind  of  information.  WSDL  and  OWL-S  descrip¬ 
tions  are  also  generated  for  these  local  services  so  that  they  can  be  composed  and 
executed  in  the  same  way  as  other  remotely  available  services. 

Finally,  some  information  gathering  services  were  implemented  as  direct  Java 
calls  from  SHOP2  over  a  Java/SHOP2  bridge.  For  example,  we  have  a  service 
which  asks  the  user  for  acceptable  distances  to  the  treatment  center  by  popping 
up  a  window  on  the  user’s  client  to  accept  input.  Changing  the  data  entered  at 
this  point  will  possibly  yield  a  different  plan  to  be  generated  allowing  the  planner 
produce  custom  plans  depending  on  personal  preferences. 

•  We  also  encoded  a  description  of  how  to  compose  Web  Services  for  tasks  such 
as  the  one  faced  by  Bill  and  Joan  in  section  2  in  OWL-S.  The  description  is  given 
as  a  OWL-S  composite  process  that  is  composed  of  several  other  composite  pro¬ 
cesses  that  are  defined  as  sequence,  choice  or  unordered  processes.  This  OWL-S 
description  constitutes  the  top  level  composite  process  described  in  Section  5.1 
and  is  translated  into  a  SHOP2  domain  for  planning.  We  encode  most  of  the  con- 
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straints  mentioned  in  section  2  as  Web  Service  preconditions.  Right  now,  there 
is  no  standard  process  modeling  language  for  specifying  Web  Service  precondi¬ 
tions.  Therefore,  we  directly  encode  the  Web  Services  preconditions  in  SHOP2 
format. 

Figure  4  shows  the  various  components  of  the  system  7  and  the  results  achieved 
from  a  sample  run  of  the  example  domain.  The  user  starts  with  a  simple  user  in¬ 
terface  where  an  OWL-S  service  description  for  any  desired  task  can  be  loaded. 
When  the  service  description  for  the  example  domain  is  selected,  a  form  to  enter 
the  required  parameters  for  the  task  is  presented  to  the  user.  This  form  is  generated 
based  on  the  ontologies  used  to  describe  the  input  parameters  of  the  service.  The 
UI  will  also  automatically  fill  out  some  of  the  fields  such  as  the  home  address  from 
a  user  specified  knowledge  base. 

Once  all  the  input  parameters  are  provided  SHOP2  starts  the  planning  process  us¬ 
ing  the  domain  description  obtained  from  the  translation  of  the  OWL-S  files.  Note 
that  the  service  selected  in  the  UI  is  specified  by  an  “abstract”  task  list,  that  is,  a  set 
of  tasks  which  can  be  achieved  in  a  variety  of  ways.  In  order  to  “execute”  (it  would 
be  better  to  say,  “perform”,  or  “achieve”)  this  service  we  must  decompose  these 
abstract  tasks  into  actions  (services)  that  we  can  actually  invoked.  SHOP2  decom¬ 
poses  the  top  level  task  into  smaller  subtasks,  and  of  course  there  may  be  multiple 
different  decompositions  for  any  given  task.  For  example,  one  decomposition  for 
the  top  level  task  yields  a  task  to  schedule  two  appointments  on  the  same  day  for 
the  same  person  whereas  another  decomposition  will  yield  a  task  to  schedule  two 
appointments  on  two  different  days  for  two  different  drivers  (see  Section  2  for  more 
information  on  domain  characteristics).  Another  example  abstract  task  is  to  find  the 
availability  of  the  prescribed  medicine  in  an  online  pharmacy  store.  A  decomposi¬ 
tion  for  this  task  will  include  all  the  different  Web  Services  for  different  online 
stores.  These  decompositions  are  statically  given  in  the  OWL-S  service  descrip¬ 
tions  but  one  can  imagine  a  more  dynamic  setting  where  a  Web  Service  repository 
is  queried  for  possible  decompositions. 

The  SHOP2  planner  will  execute  the  information-providing  Web  Services  to  gather 
the  necessary  information  for  plan  generation,  e.g.  get  the  available  appointment 
times  from  hospitals.  Based  on  the  collected  information  the  planner  will,  if  possi¬ 
ble,  produce  a  plan  that  is  a  valid  decomposition  of  the  top  level  task.  This  plan  is 
simply  a  sequence  of  atomic,  directly  executable  Web  Services  such  as  “order  the 
medicine  from  the  online  pharmacy  store”,  “make  the  appointment  in  the  hospital 
for  the  treatment”,  and  “update  my  personal  calendar  with  the  appointment  info”. 
User  has  the  option  to  view  the  details  of  the  plan,  reject  the  plan  if  desired,  and 
re-plan  with  a  new  set  of  constraints. 

To  test  the  effectiveness  of  our  approach,  we  have  run  SHOP2  on  several  instances 

1  This  system  was  demonstrated  in  the  Developer’s  Day  of  the  12th  WWW  conference  in 
Budapest,  Hungary 
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of  the  example  problem.  These  problem  instances  varied  from  cases  where  it  was 
easy  to  schedule  satisfactory  appointments  to  a  case  in  which  no  nearby  treatment 
centers  had  treatment  time  slots  that  were  close  together,  so  that  Bill  and  Joan 
would  both  have  to  drive  Mom  for  treatments  on  separate  days.  In  all  of  these 
cases,  SHOP2  was  easily  able  to  find  the  best  possible  solution.  Figure  4  shows  a 
snapshot  of  the  running  system  and  the  interaction  between  different  components 
of  the  system. 


7  Discussion 


7.1  Using  Semantic  Web  Knowledge  Bases 


SHOP2  represents  the  state  of  the  world  as  a  set  of  ground  logical  atoms.  SHOP2 
uses  axioms  which  are  generalized  versions  of  Horn  clauses  to  infer  conditions  that 
are  not  explicitly  asserted  in  the  current  state.  SHOP2’s  theorem  prover  makes  a 
closed-world  assumption.  In  contrast,  Semantic  Web,  and  particularly  OWL,  has 
an  open-world  assumption.  The  inferences  in  OWL  are  done  with  respect  to  the 
OWL  Semantics[14].  OWL  DL  species  of  the  language  can  be  directly  mapped  to 
SHION(D)  Description  Logic  (DL)[15]  which  itself  is  a  decidable  subset  of  first 
order  logic. 

Unfortunately,  it  is  not  possible  to  directly  express  the  semantics  of  OWL  DL  using 
SHOP2  axioms.  Therefore  using  SHOP2’s  theorem  prover  directly  causes  us  to 
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lose  the  inferencing  capability  normally  an  OWL  reasoner  possesses.  Furthermore, 
the  size  of  the  data  involved  in  the  planning  process  over  Semantic  Web  will  be 
much  bigger  than  the  ones  encountered  in  classical  planning  problems.  The  state 
of  the  world  consists  of  all  the  information  coming  from  ontologies  either  stored 
locally  or  found  remotely  on  the  Web.  Therefore,  the  theorem  prover  should  be  able 
to  work  in  Web  scale,  with  thousands  or  maybe  hundreds  of  thousands  of  facts  and 
axioms.  SHOP2’s  inferencing  capabilities  are  not  satisfactory  for  the  expressivity 
and  the  scalability  needed  to  deal  with  knowledge  bases  found  on  Semantic  Web. 

It  is  possible  to  completely  replace  the  theorem  prover  SHOP2  uses  with  a  new  one. 
As  long  as  the  theorem  proving  is  decidable  and  the  theorem  prover  is  sound  and 
complete  then  the  soundness  and  completeness  of  the  planner  is  ensured.  So,  we  can 
use  an  OWL  reasoner  to  reason  about  the  state  of  the  world.  On  this  model,  the  state 
will  be  simply  represented  as  an  OWL  knowledge  base.  The  precondition  checking 
is  equivalent  to  querying  the  knowledge  base  and  applying  effects  is  equivalent 
to  adding  and  deleting  facts  from  the  knowledge  base.  If  we  restrict  ourselves  to 
the  OWL  DL  language  then  we  can  use  sound  and  complete  DL  reasoners  for  this 
purpose.  Also  there  exists  DL  reasoners  specialized  to  handle  very  large  knowledge 
bases  [16].  Therefore,  we  can  solve  both  the  expressivity  and  scalability  problems. 

Using  a  DL  reasoner  inside  SHOP2  planner  brings  out  some  issues  that  classical 
planning  theory  has  not  addressed  thoroughly.  In  general,  classical  planners  do  not 
let  axiomatic  inference  at  all  or  only  allow  a  restricted  form  of  inference.  For  ex¬ 
ample,  secondary  relations,  relations  whose  values  can  be  deduced  from  other  rela¬ 
tions,  are  allowed  to  appear  only  in  preconditions  but  not  in  effects  to  avoid  certain 
complications  [17,  P.  42].  Any  property  in  OWL  that  is  defined  to  have  an  inverse 
property  can  be  seen  as  a  secondary  relation  because  the  value  for  that  property  can 
be  deduced  from  its  inverse  property.  Either  the  planner  should  not  accept  operator 
descriptions  that  use  these  properties  in  effects  or  it  should  define  the  semantics  as¬ 
sociated  with  it.  The  semantics  may  require  that  if  a  relation  is  in  the  delete  list  and 
the  property  used  in  the  relation  has  an  inverse  property  then  the  inverse  relation 
will  also  be  deleted. 

As  an  initial  attempt  to  investigate  the  applicability  of  the  idea,  we  have  incorpo¬ 
rated  the  OWL  DL  reasoner  Pellet  [18]  into  SHOP2.  To  avoid  the  problems  men¬ 
tioned  above  we  have  considered  only  a  restricted  set  of  process  definitions  where 
preconditions  and  effects  consist  of  ABox  expressions  and  effects  do  not  mention 
secondary  relations.  It  was  possible  to  represent  the  process  descriptions  used  in 
the  example  defined  in  Section  2  with  these  restrictions.  Our  initial  observations 
showed  that  using  a  DL  reasoner  increased  the  amount  of  time  required  for  plan¬ 
ning  but  overall  planning  time  was  still  dominated  by  the  time  spent  for  remote 
Web  Service  execution.  Of  course,  the  reasoning  time  is  related  to  the  structures  of 
the  ontologies  used  and  having  very  complex  definitions  could  effect  the  reasoner 
performance  significantly.  As  a  future  work  we  are  continuing  to  investigate  this  in 
detail  along  with  the  effects  of  allowing  more  expressive  DL  constructs  in  operator 
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definitions. 


7.2  Information  Gathering  During  Planning 


There  is  a  fundamental  difference  between  exclusively  information-providing  and 
possibly  world-altering  atomic  processes.  We  typically  want  to  execute  information¬ 
providing  atomic  processes  at  various  points  in  the  planning  process,  while  we 
never  want  to  execute  world-altering  ones.  Contrariwise,  at  composition  execution 
time,  the  primary  interest  is  in  the  execution  of  world- altering  processes.  Indeed, 
in  our  system  we  do  not  include  any  information-providing  processes  in  compo¬ 
sitions.  Furthermore,  currently  we  do  not  permit  world-altering  processes  to  be 
information-providing,  at  least  in  the  sense  that  they  must  have  no  outputs.  This 
simplification  made  the  system  fairly  easy  to  implement  without  substantial  modi¬ 
fication  of  SHOP2. 

However,  mapping  information-gathering  processes  to  so-called  “book-keeping” 
operators  is  somewhat  unaesthetic.  In  the  translation  algorithm  we  described,  for 
each  atomic  process  that  does  not  have  any  effects  a  book-keeping  operator  is  cre¬ 
ated  with  a  precondition  that  contains  the  external  call  to  execute  the  service  and  an 
effect  to  assert  the  output  results  as  knowledge  effects.  The  book-keeping  operator 
appears  as  a  subtask  in  the  method  definition  that  uses  the  result  of  that  service. 
But,  these  operators  are  treated  specially  by  SHOP2  and  they  never  appear  in  the 
resulting  plans. 

It  is  also  possible  to  directly  encode  the  information-providing  operators  in  the 
preconditions  of  the  calling  methods.  The  external  call  to  service  execution  would 
be  put  into  the  method’s  precondition  instead  of  the  intermediate  book-keeping 
operator.  The  output  of  the  information-providing  service  would  be  stored  in  a  local 
variable  using  SHOP2’s  assign  feature.  We  don’t  need  to  store  results  globally  since 
by  definition  only  the  enclosing  process  should  be  able  to  access  the  results  of 
a  subprocess.  Using  local  variables  proves  to  be  a  more  efficient  way  to  handle 
outputs  since  the  overall  number  of  facts  stored  in  the  current  state  are  not  effected 
by  the  information  gathering  services. 

This  different  encoding  technique  has  some  consequences.  For  example,  normally 
it  is  possible  to  define  preconditions  for  information-providing  services.  While  the 
book-keeping  operators  can  be  used  to  represent  these  conditions,  the  new  encoding 
method  does  not  keep  this  information.  As  far  as  the  correctness  of  the  plan  is  con¬ 
cerned,  this  is  not  really  a  problem.  We  can  directly  execute  information-providing 
services  and  if  the  precondition  of  that  service  is  not  satisfied  the  service  will  sim¬ 
ply  fail  to  execute.  Checking  preconditions  is  more  efficient  than  trying  to  execute 
the  service.  For  typical  public  information-providing  services,  there  are  no  adverse 
consequences  to  trying  to  execute  the  services.  In  a  situation  where  attempting  a  in- 


26 


formation  Web  Service  call  was  expensive  or  harmful,  we  would  have  to  fall  back 
on  our  prior  encoding. 

Another  issue  related  to  the  performance  arises  when  information  gathering  and 
world  altering  services  are  used  together  inside  sequences.  For  example,  an  infor¬ 
mation  gathering  service  may  be  defined  in  between  two  world  altering  actions. 
When  this  information  providing  service  is  encoded  in  the  precondition  of  the 
method  it  will  be  evaluated  before  both  of  the  world  altering  services.  This  will 
not  effect  the  resulting  plan  in  any  way  but  may  have  some  impact  on  the  perfor¬ 
mance.  If  during  planning  process  it  turns  out  that  the  first  world  altering  action  is 
not  applicable  in  the  current  state  then  the  time  spent  to  execute  the  information 
gathering  service  is  wasted. 

So  far  we  have  only  considered  the  cases  where  we  explicitly  know  which  services 
will  provide  the  information  needed  for  the  given  task.  But  actually  information 
gathering  itself  can  be  seen  as  another  planning  problem  [19].  As  discussed  in  the 
previous  section,  precondition  checking  is  reduced  to  query  answering  on  Seman¬ 
tic  Web.  If  the  information  required  to  answer  the  query  is  not  present  then  we 
can  search  for  the  services  who  can  supply  the  necessary  data.  This  process  can  be 
done  as  a  goal  oriented  planning  process  [19]  and  SHOP2  could  call  another  plan¬ 
ner  for  this  purpose.  It  is  also  possible  that  information  providing  services  have  a 
hierarchical  structure  similar  to  the  world  altering  ones.  Then  we  can  use  SHOP2 
recursively  to  first  generate  a  plan  for  information  gathering  step,  execute  this  plan 
to  get  the  information  and  then  use  this  information  to  solve  the  initial  planning 
problem. 


8  Related  Work 


Mcllarith  and  Son  [9,12]  proposed  an  approach  to  building  agent  technology  based 
on  the  notion  of  generic  procedures  and  customizing  user  constraints.  They  adapt 
and  extend  the  Golog  language  to  enable  programs  that  are  generic,  customizable 
and  usable  in  the  context  of  the  Web.  They  augment  a  ConGolog  interpreter  that 
combines  online  execution  of  information-providing  services  with  offline  simula¬ 
tion  of  world  altering  services.  Our  approach  is  very  similar  to  this.  A  general 
logic-based  system  has  the  ability  to  do  arbitrary  reasoning  about  the  theory  but  in 
general  we  suspect  that  a  logic  based  approach  will  not  be  as  efficient  as  an  HTN 
planner. 

Matskin  and  Mao  [20]  applies  software  synthesis  and  composition  methods  to  Web 
Services  composition.  Their  work  is  based  on  similarities  between  Web  Service 
composition  and  component-based  system  development  in  software  engineering. 
They  use  OWL-S  for  service  descriptions  and  adopt  Structural  Synthesis  Program 
(SSP)  method  for  automated  service  composition.  Service  composition  is  based 
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on  the  input-output  information  of  services  components  and  requires  little  domain 
knowledge.  This  approach  treats  each  service  as  an  atomic  entity  without  inspecting 
the  internal  process  model  and  therefore  lacks  the  ability  to  reason  about  different 
decompositions  in  a  composite  process. 

RETSINA  [21]  is  an  open  multi-agent  system  that  provides  infrastructure  for  differ¬ 
ent  types  of  deliberative,  goal  directed  agents.  RETSINA  system  includes  a  planner 
based  on  the  HTN  planning  paradigm.  The  RETSINA  planner  also  extends  HTN 
planning  by  adding  interleaving  of  planning  and  execution  which  basically  allows 
the  actions  execute  before  a  plan  is  completely  formed,  similar  to  our  approach. 
Paolucci  et  al.  [22]  describes  using  RETSINA  planner  in  the  context  of  creating  au¬ 
tonomous  Web  Services  that  can  automatically  interact  with  each  other.  However, 
authors  do  not  give  details  about  how  HTN  planning  is  employed  in  the  system. 
It  is  not  clear  whether  OWL-S  Process  Model  was  used  or  planning  domain  was 
given  a  priori  to  the  planner  agent.  For  this  reason,  we  cannot  make  a  comparison 
with  our  approach. 


9  Conclusion 


In  this  paper,  we  have  defined  a  translation  from  OWL-S  process  models  to  the 
SHOP2  domains,  and  from  OWL-S  composition  tasks  to  SHOP2  planning  prob¬ 
lems.  We  have  described  our  implemented  system  which  performs  this  translation, 
uses  an  extended  SHOP2  implementation  to  plan  with  and  over  the  translated  do¬ 
main,  and  then  executes  the  resulting  plans.  In  the  process  of  defining  the  translation 
and  building  the  system,  we  observed  that: 

•  In  our  current  approach,  the  planner  always  executes  output  producing  actions  as 
it  plans.  While  this  is  fine  for  many  situations,  it  may  not  always  be  appropriate. 
For  example,  the  execution  of  some  Web  Services  may  take  a  very  long  time. 
It  would  be  better  if  the  planner  could  continue  to  plan  while  waiting  for  this 
information. 

•  In  our  paper,  we  assume  that  all  effects  are  physical.  In  complex  situations,  there 
may  be  other  changes,  such  as  in  the  mental  states  of  the  agents  involved,  that 
are  not  modeled.  We  will  explore  this  problem  in  our  future  work. 

•  Information  providing  (whether  exclusively  so,  or  not)  is  likely  to  be  a  signifi¬ 
cant  fraction  of  the  available  and  salient  Web  Services.  Many  Web  contexts  seem 
to  be  information  rich  but  action  poor.  In  such  environments,  we  would  want  to 
reconsider  the  strict  partition  of  services  into  exclusively  information  providing 
and  output  free.  For  example,  world- altering  services  with  outputs  might  supply 
information  needed  to  decide  subsequent  courses  of  action.  Clearly,  such  a  ser¬ 
vice  shouldn’t  be  executed  at  planning  time,  which  suggests  that  we  will  need  to 
investigate  generating  conditional  plans  by  SHOP2  style  HTN  planning. 

Conditional  plans  will  also  help  mitigate  the  constraint  on  information  change 
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during  planning.  Currently,  both  for  theoretical  and  practical  reasons,  we  only 
execute  an  information  providing  process  once  during  planning  for  any  given 
input,  and  subsequently  retrieve  a  cached  result.  Given  SHOP’S  speed,  this  is 
not  that  unreasonable  a  restriction  for  many  cases,  but  conditional  plans  would 
permit  planning  for  various  contingencies. 

These  considerations  raise  a  host  of  issues  regarding  plan  time  vs.  composition 
execution  time  execution  of  information  providing  processes,  including  those 
of  deciding  which  such  processes  to  execute  only  during  planning,  only  during 
plan  execution,  and  during  both.  Furthermore,  in  complex,  long  running  planning 
sessions,  it  might  make  sense  to  refresh  the  monitors  cache  for  certain  services 
at  intervals.  Presumably,  OWL-S  descriptions  will  be  enriched  to  help  support 
the  requisite  analysis.  We  intend  to  explore  these  issues  in  future  work. 

•  Compared  the  complexities  raised  above,  composite  processes  raise  no  addi¬ 
tional  or  special  problems  —  encoding  them  as  SHOP2  methods  seems  correct 
and  straightforward,  modulo  the  need  to  extend  SHOP2  to  handle  concurrency. 

•  Simple  processes  are  the  odd  duck  of  the  lot.  Though  various  members  of  the 
OWL-S  coalition  have  suggested,  in  conversation,  that  simple  processes  were 
intended  to  support  HTN  planning,  we  found  them  neither  necessary,  nor  conve¬ 
nient,  nor  useful.  In  part,  their  lack  of  a  clear  semantics,  particularly  with  regard 
to  the  relationship  of  their  inputs,  outputs,  preconditions,  and  effects  to  those  of 
their  corresponding  atomic  or  composite  processes.  Furthermore,  while  the  lan¬ 
guage  of  the  technical  overview  [3]  suggests  that  a  given  simple  process  can  be  a 
view  of  one  atomic  process  or  one  composite  process,  but  not  both,  neither  the 
language  nor  the  ontology  actually  require  this  restriction.  We  speculated  that 
this  would  make  simple  processes  useful  for  specifying  a  range  of  alternative 
composition  paths,  but  it  wasn’t  clear  that  this  was  really  more  convenient  (for 
our  purposes)  than  using  the  Choice  control  construct. 
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